Hello! This looks like a very useful package. Thank you for taking the time to publish it!

There are several linting fixes to be made to the package data, which I've noted in my review. (The PR has inspired ocurrent/opam-repo-ci#370, which will be a useful addition :) ).

I would be in favor of getting the tests fixed here before we merge it. While we can make exceptions, every exception we make contributes to making the CI results less accurate, undercutting the value proposition in our promising (and IMO, already quite successful) experiment in ecosystem-wide CI/CD.

There are two main benefits:

• Benefit for users of a package: Users can have good confidence that it will work as expected on tested platforms (of which there are many).
• Benefit for authors of a package: When the package tests are reliable, we are able to give reliable results in our reverse dependency tests. This means, if any of your dependencies introduce changes that break your package, we will ensure that unintended breakage is fixed or that intended breakage is guarded by adding an upper bound to the opam file.

With this in mind, I would propose that we address

the absence of network available on the test machines

following the example of #25527 (comment), where tests that require network access are moved into a distinct dune target https://github.com/savonet/ocaml-ffmpeg/blob/f97819265c35375b79232443665fbc413fda45f2/test/dune#L6. Conversely, I think you could change the build instructions to use a different target for with-test, but I think that would go against the grain of the dune packaging flow.

If you are open to one of these fixes, but don't have the bandwidth to put it in place, I'd be happy to lend a hand.